The DBMS must support organizational requirements to disable user accounts after an organization-defined time period of inactivity.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-52269	O112-C2-013800	SV-66485r1_rule		Medium

Description

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Unused or expired DBMS accounts provide a means for undetected, unauthorized access to the database. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.

STIG	Date
Oracle Database 11.2g Security Technical Implementation Guide	2015-06-23

Details

Check Text ( C-54325r1_chk )

If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, stop here: this is not a finding against the DBMS. For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed. If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding. - - - - - Check to see what profile a user is associated with, if any, with this query: SQL> select username, profile from dba_users where username = '&Enter_Username'; Then check the profile to see what the password_life_time is set to in the table dba_profiles; The password_life_time is a value stored in the column named resource_name. SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'PASSWORD_LIFE_TIME'; - - - - - The following are notes on a method suggested by Oracle. In SRG-APP-000075-DB-000029 - The DBMS must, upon successful login, display to the user the date and time of the user's last login advocated using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.login_audit_info_all and trap login information with a login trigger. Check for the existence of the sys.login_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue. $ sqlplus connect as sysdba SQL> select count(*) from SYS.LOGIN_AUDIT_INFO_ALL; If the count is greater than zero, then the table exists and data is being inserted.

Fix Text (F-57085r1_fix)

If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement: ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35; (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples.) If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days. - - - - - The following are notes on a method suggested by Oracle. Check either the login_audit_info_all or the dba_audit_session to see what users have not logged in for the site-defined number of days. If the login_audit_info_all exists, execute the following query to get a report of the users who have exceeded the site-specific guidelines and lock those accounts. Generate a report to see what users have not logged in in the last 30 days or whatever the site-specified expiration days requirement is. sqlplus connect as sysdba - If sys.login_audit_info_all exists and contains rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col user_id format a30 SQL>col logoff_day format a20 Sal>select user_id, logoff_day from sys.login_audit_info_all where sysdate - logoff_day > &site_specified_expiration_days; sqlplus connect as sysdba - If sys.login_audit_info_all does not exist or contains no rows, use the following query to see if there are any users who have not logged in for a period of time that is defined as the amount of time required to generate a locked account. SQL>set linesize 121 SQL>col username format a30 SQL>col timestamp format a20 SQL> select username, timestamp from dba_audit_session where action_name = 'login' and sysdate - timestamp > &site_specified_expiration_days; Take the user returned from this report and expire the account. SQL> alter user &username account lock;